<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>敏捷</title>
    <style type="text/css">
        .content {
            width: 800px;
            margin: auto;
        }
        
        .content h1 {
            font-size: 28px;
            font-family: microsoft yahei;
            text-align: center;
        }
        
        .content .box {
            text-align: center;
        }
        
        .time,
        .news {
            font-size: 14px;
        }
        
        .time {
            color: lightblue;
        }
        
        .news {
            color: #990000;
        }
        /* 属性选择器 */
        
        .box input[type=text] {
            color: red;
        }
        
        .box input[type=button] {
            color: green;
            font-weight: 700;
        }
        
        .content p {
            text-indent: 2em;
            line-height: normal;
        }
    </style>
</head>

<body>
    <div class="content">
        <h1>概念，可以参考敏捷宣言，强调适应变化，四句指导</h1>
        <div class="box">
            <span class="time">2014年07月16日 20:11</span><span class="news">个体和互动 高于 流程和工具
            <a href="#">收藏本文</a>
        </span>
            <input type="text" value="请输入查询条件">
            <input type="button" value="搜索">
        </div>
        <hr>
        <p>
            1、概念
            <br> 可以参考敏捷宣言，强调适应变化，四句指导 个体和互动 高于 流程和工具（动员每个人积极交流，相互之间可以 battle，头脑风暴）； 工作的软件 高于 详尽的文档（好的代码是不需要注释和文档的，顶多有一些规范指南一类的在线协作文档）； 客户合作 高于 合同谈判（真心实意为客户创造价值，而不止于眼前的功能交付，这个很难，由此还专门有一个角色去 control 这件事）； 响应变化 高于 遵循计划（计划是赶不上变化的，随时改需求随时变动迭代计划，有迭代的概念）； 基于于右边，而更注重左边的价值，并不是说完全抛弃传统的瀑布式开发。
        </p>
        <p>
            2、人员架构 <br>因为公司没有所谓的各种领导，这里就说下交付组里，我所见的一些角色，也是每天在一起工作的小伙伴： PM：项目管理者，这里不是项目经理，负责和客户签合同，各种会议的组织者，没有项目经理那种权利 BA：业务分析师，专门和客户谈需求，超强的交流和控制客户的能力，几乎每天都和客户泡在一起开会过需求，疯狂开会，驱动客户（我们组的BA是御姐型的，气场极强） QA：测试人员 DEV：开发人员，其中有掌握技术话语权的 TL PO：比较特殊，是客户某的部门领导人，一般和
            PM 单独沟通，几乎没出现过，网友一样的存在 一个团队一般 1 PM、1 BA、1 QA 、6 DEV (三前三后，至少两个TL) 这里没有 MS，所以每个人都是 SM，

        </p>

        <p>
            3、会议
            <br> IPM：迭代会议，每个迭代开始之前开一次，主要是排下个迭代的故事卡，并给每张卡估点，我遇到的是两周一个迭代（一般会有卡墙，有物理的，也有线上的） Showcase：开发成果展示，每个迭代结束开一次，一般是BA或QA给客户演示上个迭代做的功能，当然也是优化和新改动提得最多的时候 Retro：回顾会议，每个迭代结束开一次，讨论上个迭代团队做得好和做得不好的事（不是针对和人，不含人身攻击），并给出改进方案，在下个迭代中执行 Stand Up：每天早上的站会，大家站成一圈，一般由
            PM 主持，轮流阐述自己的昨天工作内容和工作进度，和今天要完成的工作，以及遇到的一些问题，及时反馈出来（我们组有个小龙猫的毛绒玩具，大家挨个传递，挨个阐述） 每天还有 Code Review，动态安排时间，我们团队一直坚持，刚开始是前后端一起过昨天每个人写的代码，后面时间太长，就前后端分开。大家一起来找茬，你的命名和代码逻辑划分，代码风格，都有个能会被挑刺。在相互找茬的过程中，坚持下去，对个人的成长有很大很大的帮助。

        </p>

        <p>
            4、写代码<br> DEV 要做开发，就要先领故事卡，俗称开卡，自己选好一张故事卡，拉上BA和QA去过其中的细节，理清细节，然后才能上手开发，开发完后再拉上BA和QA去结卡，检查卡中的功能是不是都完成了，有问题就被打回去改，直到BA和QA觉得完善了，才能关卡。。。 代码质量要求很严格，遵循 TDD，前端有 lint，有单元测试（不能偷懒，而且有覆盖率要求），有 e2e 测试（必须写，和QA一起看），当你的代码走过这三个流程，提交到公共仓库，CI 自动构建会拉你的代码，再走一遍测试（挂了就要修代码），然后自动发布新版本到
            Dev 环境。 你以为这就完了？还有代码嗅探器，时刻在扫描代码仓库，有两个重复的函数不行、重复率太高不行、使用了骚代码去做类型转换之类的不行、空间内有命名重叠不行。。。。这一套下来，再加上 code review，菜鸟开发每天一半的时间都在改昨天的代码。 项目还有规定，CI 不能红过夜，当天的问题当天要修好。。。。 及时响应，快速交付，随时可交互给用户 po 任务优先级，快速交付，产品方向与愿景，定义产品发布内容，产品交付时间 敏捷计划会，一个迭代一次， 任务明确，需求划分，故事点划分=小的任务点
            每日立会，从昨天到现在完成了什么，从现在到明天我计划完成什么，遇到了什么阻ai，抛出问题 敏捷评审会，向客户或利益相关的人员展示demo，展示我们team在本次迭代中完成了什么，实现了什么功能 敏捷回归会，月尾，每个迭代结束后进行，经验和教训，定量分析：team在这个周期是否完成了目标，迭代速率等，客户满意度，计划发布日期与实际发布日期，团队满意度，生产环境bug数，生产bug解决时间，用户故事 定性分析，team哪些做得好的，不好的，改进的，提取一两条建议在下一个sprint执行
            开发完成后自测跑ut—功能测试 测试完成后提交，跑ci流程如果ci没过，代码有问题<strong>code review 主分支代码随时可交付</strong>

        </p>
    </div>






</body>

</html>